> we received a call from our provider noc today indicating their links > were saturated as a result of one of our hosts. we tracked it down to > a "talk" program that had been running for 1.5 days (the noc only > indicated about 4 hours of the intense activity when they called). it > looked legit with no obvious malicious intentions (we didn't find any > questionable looking programs such as "flash" or "talk" ) : > > xxxxx 814 34.8 0.4 84 252 ? R Nov 6336:04 talk aakhtar orion.it.lu > c.edu > > anything new on this ? We had the same thing happen here last year. A talk process was trying to send lots of UDP traffic to an unreachable port. Typically: 22:11:43.005886 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.005994 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.006097 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.006562 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.007048 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.007611 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.007695 viper.edb.tih.no > eik5.idt.unit.no: icmp: viper.edb.tih.no udp port talk unreachable 22:11:43.007962 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 22:11:43.008083 eik5.idt.unit.no.3056 > viper.edb.tih.no.talk: udp 76 It was able to completely swamp a 64 kbit/s line. From what we could see, this was not done with any malicious intent - we believe it happened due to a bug in talk. Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no